Providing shipping details on a pay transaction via the internet

ABSTRACT

E-commerce personal account numbers, shipping addresses, and other data may be tokenized to facilitate transaction completion by establishing e-commerce browser standards. Tag data may be received from a website associated with an e-commerce transaction. The tag data may include an indication that a merchant payment webpage is configured to receive a payment transaction via a token. Tokens may then be created from a personal account number and a shipping address corresponding to the personal account number in response to a request for token data.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No.62/321,094, entitled “EXPEDITED E-COMMERCE TOKENIZATION” filed Apr. 11,2016 and priority to Indian patent application IN 6294/CHE/2015,entitled “A SYSTEM AND METHOD FOR CONDUCTING A TRANSACTION” filed Nov.23, 2015. The disclosures of both applications are incorporated hereinby reference.

BACKGROUND

The background description provided herein is for the purpose ofgenerally presenting the context of the disclosure. Work of thepresently named inventors, to the extent it is described in thisbackground section, as well as aspects of the description that may nototherwise qualify as prior art at the time of filing, are neitherexpressly nor impliedly admitted as prior art against the presentdisclosure.

When cards are used for payment purposes during checkout, E-Commercemerchants as well as payment service providers (PSPs) may traditionallyallow browser auto-form fills during checkout to expedite the consumer'spayment process. Merchants and PSPs then use the card information storedon file during this process. However, when a card on file has expired,the merchant/PSP has to nudge the consumer to either provide therefreshed expiry date or select another card. This practice often leadsto consumer drop-offs.

When these merchants/PSPs tokenize the cards using a token service tokenrequestor such as Browser Partners or E-Commerce Enablers, while thebenefits of tokenization are reaped, these token numbers cannot beauto-filled or key entered in the consumer browser.

Likewise, the use of communication devices such as mobile phones inconducting financial transactions is becoming widespread. In some cases,mobile phones enable consumers to scan graphical codes, such as quickresponse barcodes, to initiate payments in favor of a merchantdisplaying the graphical code.

While these techniques enable consumers to quickly initiate a payment infavor of a merchant, in many transaction types, additional informationwill be required by the merchant. For example, in the case of anelectronic commerce (e-commerce) transaction, the merchant willtypically require a shipping address and possibly contact information ofthe consumer to enable the merchant to ship the purchased product to theconsumer.

Requiring the user to provide such further information may slow down theprocess of transacting and may in turn increase the difficultyexperienced by consumers in transacting.

It may further be troublesome for merchants to receive a consumer'sshipping address from one source and confirmation of payment fromanother source. Receiving information from disparate sources mayincrease back-end processing which the merchant needs to perform, forexample, in tying the shipping address of the consumer received from onesource with the payment confirmation received from another source suchas the merchant's financial institution.

SUMMARY

Features and advantages described in this summary and the followingdetailed description are not all-inclusive. Many additional features andadvantages will be apparent to one of ordinary skill in the art in viewof the drawings, specification, and claims hereof. Additionally, otherembodiments may omit one or more or all of the features and advantagesdescribed in this summary.

Systems and methods described herein may expedite e-commercetokenization and transaction completion by establishing e-commercebrowser standards around tokenization for merchants and PSPs, reducingfriction during checkout thereby increasing conversion rates, andcircumventing the expired cards problem with tokenization by requestinga valid and unique cryptogram. Another aspect may include tokenizationof the card used in checkout.

A method for conducting a transaction in which funds are transferredfrom a payer to a payee, may be conducted at an issuer server computerassociated with the payer. The method may include receiving, from acommunication device of the payer, a transaction message including anamount associated with the transfer of funds, an account identifier ofthe payee, and a permission indication that presents the payer'sapproval or denial in respect of sharing with the payee personalinformation requested by the payee. If the permission indicationindicates that the requested personal information may be shared with thepayee, the method may generate a transaction request message includingthe amount, the account identifier of the payee and the requestedpersonal information. The method may then transmit the transactionrequest message for receipt by an acquirer server computer associatedwith the payee for processing the transaction and conditional forwardingof the requested personal information to the payee.

A further feature provides for the method to include, if the permissionindication indicates that the requested personal information may not beshared with the payee, generating a transaction request messageincluding the amount and the account identifier of the payee.

Still further features provide for the transaction to be a pushtransaction; and for the transaction request message to an originalcredit transaction request message.

A yet further feature provides for the personal information to includeone or more of the group of: a shipping address, an email address, and aphone number.

An even further feature provides for the permission indication toinclude the requested personal information.

A further feature provides for the method to include retrieving thepersonal information from a data record associated with the payer.

A still further feature provides for the method to include receiving atransaction response message confirming or denying the transaction.

Yet further features provide for transmitting the transaction requestmessage for receipt by the acquirer server computer to includetransmitting the transaction request message to the acquirer servercomputer via a payment processing network, and for the accountidentifier of the payee to include routing information usable by thepayment processing network in routing the transaction request message tothe acquirer server computer. The payment processing network may be aninteroperable payment processing network.

A method may also conduct a transaction in which funds are transferredfrom a payer to a payee. The method may be conducted at a communicationdevice of the payer comprising: obtaining, from a tag, an accountidentifier of the payee and a personal information flag indicating thatpersonal information of the payer is requested by the payee; promptingthe payer for permission to share the requested personal informationwith the payee; receiving the payer's approval or denial in respect ofsharing the requested personal information with the payee; generating atransaction message including an amount associated with the transfer offunds, the account identifier of the payee and a permission indicationindicating the payer's approval or denial in respect of sharing therequested personal information with the payee; and, transmitting thetransaction message to an issuer server computer associated with thepayer for processing the transaction and conditional forwarding of therequested personal information to the payee.

A further feature provides for the tag to be one of: a radio frequencybeacon, a near sound communication beacon, or graphical code.

Still further features provide for the personal information to includeone or more of the group of: a shipping address, an email address, and aphone number, and for the personal information flag to indicate that oneor more of a shipping address, an email address, and a phone number ofthe payer is requested by the payee.

A yet further feature provides for prompting the payer for permission toshare the requested personal information with the payee to includedisplaying the personal information which will be shared with the payee.

A still further feature provides for prompting the payer for permissionto share the requested personal information with the payee to includeproviding the payer with an option to edit the personal informationwhich will be shared with the payee.

A yet further feature provides for prompting the payer for permission toshare the requested personal information with the payee to includeproviding the payer with an option to select personal information of acontact of the payer which will be shared with the payee.

A system may conduct a transaction in which funds are transferred from apayer to a payee, the system including an issuer server computerassociated with the payer, comprising: a payer messaging component forreceiving, from a communication device of the payer, a transactionmessage including an amount associated with the transfer of funds, anaccount identifier of the payee, and a permission indication indicatingthe payer's approval or denial in respect of sharing with the payeepersonal information requested by the payee; a generating component for,if the permission indication indicates that the requested personalinformation may be shared with the payee, generating a transactionrequest message including the amount, the account identifier of thepayee and the requested personal information; and, a payment networkmessaging component for transmitting the transaction request message forreceipt by an acquirer server computer associated with the payee forprocessing the transaction and conditional forwarding of the requestedpersonal information to the payee.

A further feature provides for the generating component to be for, ifthe permission indication indicates that the requested personalinformation may not be shared with the payee, generating a transactionrequest message including the amount and the account identifier of thepayee.

Still further features provide for the transaction to be a pushtransaction and for the transaction request message to be an originalcredit transaction request message.

A yet further feature provides for the personal information to includeone or more of the group of: a shipping address, an email address, and aphone number.

An even further feature provides for the permission indication toinclude the requested personal information.

A still further feature provides for the system to include a retrievingcomponent for retrieving the personal information from a data recordassociated with the payer.

A further feature provides for the payment network messaging componentfurther to be for receiving a transaction response message confirming ordenying the transaction.

A still further feature provides for the payment network messagingcomponent to transmit the transaction request message to the acquirerserver computer via a payment processing network, and for the accountidentifier of the payee to include routing information usable by thepayment processing network in routing the transaction request message tothe acquirer server computer. The payment processing network may be aninteroperable payment processing network.

A system may also conduct a transaction in which funds are transferredfrom a payer to a payee, the system including a communication device ofthe payer, comprising: an obtaining component for obtaining, from a tag,an account identifier of the payee and a personal information flagindicating that personal information of the payer is requested by thepayee; a prompting component for prompting the payer for permission toshare the requested personal information with the payee; an inputcomponent for receiving the payer's approval or denial in respect ofsharing the requested personal information with the payee; a generatingcomponent for generating a transaction message including an amountassociated with the transfer of funds, the account identifier of thepayee and a permission indication indicating the payer's approval ordenial in respect of sharing the requested personal information with thepayee; and, a transmitting component for transmitting the transactionmessage to an issuer server computer associated with the payer forprocessing the transaction and conditional forwarding of the requestedpersonal information to the payee.

A further feature provides for the tag to be one of: a radio frequencybeacon, a near sound communication beacon, or graphical code.

A still further feature provides for the personal information to includeone or more of the group of: a shipping address, an email address, and aphone number, and for the personal information flag to indicate that oneor more of a shipping address, an email address, and a phone number ofthe payer is requested by the payee.

A yet further feature provides for the prompting component to displaythe personal information which will be shared with the payee.

A further feature provides for the prompting component to provide thepayer with an option to edit the personal information which will beshared with the payee.

A still further feature provides for the prompting component to providethe payer with an option to select personal information of a contact ofthe payer which will be shared with the payee.

A computer program product may conduct a transaction in which funds aretransferred from a payer to a payee, the computer program productcomprising a computer-readable medium having stored computer-readableprogram code for performing the steps of: receiving, from acommunication device of the payer, a transaction message including anamount associated with the transfer of funds, an account identifier ofthe payee, and a permission indication indicating the payer's approvalor denial in respect of sharing with the payee personal informationrequested by the payee; if the permission indication indicates that therequested personal information may be shared with the payee, generatinga transaction request message including the amount, the accountidentifier of the payee and the requested personal information; and,transmitting the transaction request message for receipt by an acquirerserver computer associated with the payee for processing the transactionand conditional forwarding of the requested personal information to thepayee.

Another computer program product may conduct a transaction in whichfunds are transferred from a payer to a payee, the computer programproduct comprising a computer-readable medium having storedcomputer-readable program code for performing the steps of: obtaining,from a tag, an account identifier of the payee and a personalinformation flag indicating that personal information of the payer isrequested by the payee; prompting the payer for permission to share therequested personal information with the payee; receiving the payer'sapproval or denial in respect of sharing the requested personalinformation with the payee; generating a transaction message includingan amount associated with the transfer of funds, the account identifierof the payee and a permission indication indicating the payer's approvalor denial in respect of sharing the requested personal information withthe payee; and, transmitting the transaction message to an issuer servercomputer associated with the payer for processing the transaction andconditional forwarding of the requested personal information to thepayee.

Further features provide for the computer-readable medium to be anon-transitory computer-readable medium and for the computer-readableprogram code to be executable by a processing circuit.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a system including a merchant, a token requestor anda token service;

FIG. 2 illustrates a system including a merchant payment processor, atoken requestor and a token service;

FIG. 3 illustrates a method or data flow using the systems of FIG. 1and/or FIG. 2;

FIG. 4 is a schematic diagram which illustrates an exemplary system forconducting a transaction;

FIG. 5 is a block diagram which illustrates components of the systemillustrated in FIG. 4;

FIG. 6 is a flow diagram which illustrates an exemplary method forconducting a transaction;

FIG. 7 is a schematic diagram which illustrates an exemplary scenario ofthe described system and method in use from the perspective of a payer;

FIG. 8 illustrates an example of a computing device in which variousaspects of the disclosure may be implemented; and

FIG. 9 shows a block diagram of a communication device that may be usedin embodiments of the disclosure.

Persons of ordinary skill in the art will appreciate that elements inthe figures are illustrated for simplicity and clarity so not allconnections and options have been shown to avoid obscuring the inventiveaspects. For example, common but well-understood elements that areuseful or necessary in a commercially feasible embodiment are not oftendepicted in order to facilitate a less obstructed view of these variousembodiments of the present disclosure. It will be further appreciatedthat certain actions and/or steps may be described or depicted in aparticular order of occurrence while those skilled in the art willunderstand that such specificity with respect to sequence is notactually required. It will also be understood that the terms andexpressions used herein are to be defined with respect to theircorresponding respective areas of inquiry and study except wherespecific meanings have otherwise been set forth herein.

DETAILED DESCRIPTION

The present invention now will be described more fully with reference tothe accompanying drawings, which form a part hereof, and which show, byway of illustration, specific exemplary embodiments by which theinvention may be practiced. These illustrations and exemplaryembodiments are presented with the understanding that the presentdisclosure is an exemplification of the principles of one or moreinventions and is not intended to limit any one of the inventions to theembodiments illustrated. The invention may be embodied in many differentforms and should not be construed as limited to the embodiments setforth herein; rather, these embodiments are provided so that thisdisclosure will be thorough and complete, and will fully convey thescope of the invention to those skilled in the art. Among other things,the present invention may be embodied as methods, systems, computerreadable media, apparatuses, or devices. Accordingly, the presentinvention may take the form of an entirely hardware embodiment, anentirely software embodiment, or an embodiment combining software andhardware aspects. The following detailed description is, therefore, notto be taken in a limiting sense.

Payment services may be designed to make payments easier and smoother.In one aspect, payment services may receive one or more payment devicessuch as credit cards or payment accounts. The account data such asaccount number, account name, billing address, shipping address, etc.,may only need to be entered once and the payment service will securelystore the account data using an account name. In use, a user may onlyneed to have a payment system log-on and password to make a paymentusing any of the various accounts that the user has added to the paymentsystem. In operation, the payment system may not communicate an actualaccount number to a merchant but may communicate a short term accountnumber in a token for that specific transaction with the payment servicemay translate into the actual account number on the backend.

As illustrated in FIG. 1, in a payment system 100, back end components102 such as a token server 102 may include on or more modules such as aToken Requestor Browser Partners or E-Commerce Enablers 104 that may beintegrated with a token service 106 such as back-end or cloud-basedmodules executing, at least partially, on the server 102, as describedherein. Front end components 108 e.g., such as Merchants may integratewith the Token Requestor 104 to receive token data 110 (FIG. 1). Tokensmay be used by merchants and payment service providers to enableelectronic payments.

FIG. 2 may illustrate that the merchant interface 108 or a merchantpartner interface 202 e.g., Payment Service Providers PSPs, a hostedorder page, merchant payment processor interface, etc. may be integratedwith the Token Requestor 104 to receive token data 110, 204. In someembodiments, the merchant partner interface 202 may not have a directrelationship with the token service. Merchant interface 106 may receivetoken data 110, 204 from their partner interface or PSPs. Theseinterfaces may then be integrated with the Token Requestor 104 toreceive token data 110, 204. A partner interface 202 may includeprerequisite functions to make sure the electronic payment system 200works as desired. For example, a direct merchant or E-Commerce Enablermay have to adopt one or more standards, i.e., the E-Commerce browserstandard 206, and may need to make their payment page “Token Ready.” Aconsumer's browser may need to be compatible for the experience. Anentity requesting token payload from Token Requestor 104 may have theauthorized credentials.

Token Data 110, 204 may include one or more of unencrypted and encrypteddata. In some embodiments, unencrypted data of the token data 110, 204may include non-sensitive information for display purposes to theconsumer without requiring decryption. For example, the unencryptedtoken data may include a last four digits of a credit card number, orPAN, a customer ZIP code, country, or other data. In furtherembodiments, encrypted data of the token data 110, 204 may includesensitive information for transaction purposes. For example, encryptedtoken data 110, 204 may include payment fields as obtained from thetoken server which may include a token number, a token expiration date,a token cryptogram TAVV, a card or PAN number, or an ECI indicator.Consumer profile fields may also be unencrypted or encrypted, asavailable by the Token Requestor and depending on a customer's datasensitivity. For example, a billing address, a shipping address, anemail address, or phone numbers may be tokenized as encrypted orunencrypted data. Of course, any or all of the data may be tokenized asneeded by the systems and method described herein. For example, theshipping information for a purchase may be tokenized and inserted into atransaction so that a customer does not have to enter the details once apayment method is selected.

A token requestor 104 may be integrated with the token server 102. Oneor more APIs executing on the server 102 may also enroll and provisionPersonal Account Numbers PANs as well as receive cryptograms forprovisioned tokens. Table 1 below may provide an overview of the basicAPIs corresponding to the server 102 used to explain some of the usecases.

TABLE 1 API Reference Description Enroll PAN API to enroll a PAN in atoken service and also retrieve card art details for a given PAN. Asuccessful action enrolls a card with the token service for subsequentprovisioning. It also retrieves the card art metadata associated withthe card. Provision using PAN API to provision token using PANEnrollment ID. Enrollment ID Provision Token API API where tokenrequestor provides PAN data to using PAN provision a token. A successfulaction may provision a token from the Token Vault to a token requestor.Get Payment Data API API where token requestor obtains a cryptogramusing Token for a provisioned token.

FIG. 3 may illustrate one embodiment of a method or data flow 300 in thesystem 100 or 200. Each step of the method or data flow 300 may beperformed on a server or other computing device including instructionsthat, when executed by a processor, perform the action or blockdescribed herein.

At 302, a consumer browser 302 may be directed to a website interface304. In some embodiments, the interface 304 may include a merchantpayment webpage 304 a of the interface 304 that is configured toinitiate the checkout process such as when a consumer has selected itemsand is preparing to pay for the items. A local or remote shopping server(e.g., a server 203 hosting the partner interface 202) may host themerchant interface 304.

At 306, one or more tags 304 b at the merchant's payment page 304 a maybe sent to a token requestor module 312. In some embodiments, the tags304 b may include a “Token Ready” tag and/or a “Token Client ID” tag.The tags 304 b may be visible to the consumer or may only be availableto backend servers such as the payment service 308.

At 310, in response to receiving the “Token Ready” tag and/or a “TokenClient ID” tag, the token requestor module 312 may identify the page tobe “Token Ready,” validate the Token Client ID tag via the one or moretags 304 b, and, via the consumer browser module 302, present theConsumer the option to select a payment device such as an existingcredit card or a new card using the payment system. Logically, if thepage is not token ready and/or the token client ID is not validated, thecustomer may not be able to use a token-based payment service asrepresented by the flow of data 300. The token requestor 312 may be partof the shopping server 203 or may be a separate server which isphysically configured to request tokens.

At block 314, the consumer browser 302 may receive an input indicatingselection of a payment device such as a card on file or add a new cardto the payment application. The selection may be as simple as clickingon a visual representation of one of the accounts that have been addedto the payment system via the browser 304. The selection may then besent to the token requestor module 312.

At block 316, a token requestor 312 may receive token data from a tokenserver 308 at the token service 308 a for the payment device or card andother information. In some embodiments, if the payment device is anexisting card with a provisioned token, the token requestor 312 mayrequest the token server 308 for a cryptogram and receive the cryptogramusing a Get Payment Data API call to the checkout module 308 b. Infurther embodiments, if the payment device is an existing card with aprovisioned token, the token requestor 312 may request the token server308 for a further cryptogram and receive the further cryptogram using aGet Shipping Details API call to the checkout module 308 b correspondingto a token that includes the shipping details of the customer. The tokenserver 308 may be a server physically configured to handle the request,creation or provisioning, and communication of tokens. If the paymentdevice is a new card, the token requestor 312 may enroll the card andprovision the PAN first (i.e., execute both an Enroll PAN API call and aProvisioned Token API call to the checkout module 308 b), and then mayrequest a cryptogram from the token service 308 a for the token usingGet Payment Data API. A user interface may be presented to the user viathe browser 304 to assist in adding the new payment device.

At block 318, the token requestor 312 may use a Token Client ID API toencrypt the token data 110, 204 as well as other data elements providedin token data 110, 204, as described herein. The encryption may be anyknown encryption that is appropriate and widely accepted in the paymentsystem.

At block 320, the token requestor 102 may push token details to thebrowser 304 in the “Token Data” tag structure 320 a, described below,via the merchant interface 304. As the tag structure is known andstandard, the merchant interface 304 may be configured to auto fill data320 b from the payment system which may make payments easier forconsumers and may mean more sales for merchants. For example, consumershave become accustomed to shipping addresses being auto-filled and thedescribed system enables such auto-filling to continue using a paymentservice.

Further, assuming the standard is followed by other payments systems,receiving auto fill data 320 b from a variety of systems may besimplified. For example, currently Payment System A may have a namefield as the first element in a communication while Payment System B mayhave a name field as the fifth element in a communication. By followinga standard, the Merchant will not have to have separate procedures forPayment System A and Payment System B but will simply have to follow thestandard for payment system data exchange.

At block 322, the Merchant Interface 304 or PSP may obtain the tokendetails in the “Token Data” tag, and may display appropriate carddetails, shipping data, and other information from the token data 110,204 to the consumer. In some embodiments, the interface 304 may beconfigured to use a cryptogram created by the token service 308 a todecipher and display the token data within the merchant payment webpage304 a. From the displayed information, a user may be able to accept orreject the displayed card and account details.

At block 324, the consumer may review the payment device cardinformation and may submit the order. For example, if the paymentdetails are not as expected, the order may be canceled but if thepayment details are as expected, the order may proceed. In someembodiments, the Merchant Interface 304 or PSP may select to display oneor more of the following from the token data 320 a to the consumer: a)Payment data; b) Last 4 of card; and/or c) Value added data elements asdecided by the Merchant/PSP (e.g. Shipping & Billing Details).

At block 326, the merchant interface 304 or PSP may map the tokendetails to an e-commerce authorization request 326 a, and may submit therequest 326 a to the issuer server 328 through its acquiring channel forapproval. The approval may be made by an approval module 328 a which maybe local or remote to the issuer server 328 and may be physicallyconfigured to make and communicate authorization decisions.

At block 330, the e-commerce authorization request may be approved ordeclined, and the corresponding authorization response 330 a may be sentback to the merchant. If the authorization is declined, a user may bepermitted to submit the authorization data again. In some embodiments,the flow 300 may execute a Get Shipping Details API call to the checkoutmodule 308 b and insert shipping details into the transaction uponreceiving an indication that the transaction was approved.

To aid implementation of the method 300, the various requirements aswell as recommendations to Token Requestors 312, the Merchant Interface304 as well as Payment Service Providers PSPs in the payment experience,the following system elements and tags 304 b may be communicated amongthe various modules, entities, etc., of the flow 300 as follows:

“Token Ready” Tag

1. Merchant or PSP Interface 304 receiving the token details may need toenable an HTML tag on the payment page to mark it “Token Ready.”

2. Token Requestor 312 may need to be able to identify the payment pageas being “Token Ready,” and subsequently trigger the correspondingE-Commerce payment experience in executing the steps of the flow 300described herein.

“Token Client ID” tag

1. Merchant or PSP Interface 304 receiving the token details may need toenable an HTML tag “Token Client ID” tag to specify its relationshipwith Token Requestor 312.

a. Merchant Interface 304 may have a direct relationship with TokenRequestor 312, or

b. Merchant Interface 304 may be connected to the Token Requestor 312via a PSP or partner Acquirer/Gateway/E-Commerce Payment ServiceProvider.

2. Token Requestor 312 may be able to validate the “Token Client ID” tag304 b as well as use it to encrypt token data.

“Token Data” Tag 320 a

1. Token Requestor 312 may need to be able to return token detailsobtained from token server 308 required for the consumer's orderconfirmation, receipt as well as payment authorization in “Token Data”tag 320 a.

2. Merchant or PSP Interface 304 receiving token elements may need to beable to receive token data in the “Token Data” tag 320 a.

3. The value added data elements (e.g., customer shipping information asretrieved and tokenized using the Get Shipping Details API call to thecheckout module 308 b) may contain more elements than the ones specifiedin the list below, and may be dependent on their availability and datasensitivity.

Table 2, below, shows some procedures which may make the e-commercetokenization procedures described herein more expedited and efficient.

TABLE 2 Area Description Token Provisioning Merchants or PSPs may needto present their tokenization content in the service terms and privacypolicies to the cardholder prior to provisioning a token. ConsumerInterface/ Merchants or PSPs may include appropriate Customer Servicemessaging to educate cardholders on tokenization. Tokens may not beauto-filled/key-entered in the browser. Merchants or PSPs may need touse the term “digital account number” instead of the term “token” in alltheir communication with the cardholder. For consumer-receipt purposes,where the card expiration date is used today, the last four digits ofthe PAN without the expiration date may need to be used displaypurposes.

Data Encryption

The token data 110, 204, tag data 304 b and other data to implement theembodiments described herein may be encrypted. As shown in Table 3, theencryption may apply to personal account identifiers or otherinformation that may be traced to an account that is sent by the tokenrequestor 312 to the merchant or PSP interface 304.

TABLE 3 Area Description Possible Requirement Data Encryption Secureencryption of transmission and Keysizes 128-bits or highersym; securestorage of encrypted data. An Keysizes RSA Modulus 2048-bits orauthority may recommend the use of higher asym. ECC keysize of 256-symmetric e.g., AES-GCM, CBS, CCM or bits or higher. As per Industrybest asymmetric e.g., PKI keys. The practices and protocols. encryptionkeys may be securely protected. Integrity and non- Secure encryption oftransmission and Keysizes 128-bits or highersym; repudiation ofsensitive secure storage of encrypted data. An RSA Modulus 2048-bits orhigher data if applicable, for authority may recommend the use of asym.ECC keysize of 256-bits or data in transit symmetric e.g., AES-GCM, CBS,CCM or higher. As per Industry best asymmetric e.g., PKI keys. Thepractices and protocols. encryption keys may be securely protected.Transmission An authority may recommend two-way SSL/TLS securecommunication, as SSL to secure communication of per Industry bestpractices and personally identifiable information e.g., protocols.cardholder address as well as personal account identifiers e.g., token.Authentication and All communications may have UserName/Password, PIN,OAuth session management appropriate authentication methods 2.0, SAML2.0, etc., as per Industry between applications e.g., mobile app, bestpractices and protocols. web redirects or between business entitiese.g., client-to-server, server-to- server Access Control Appropriateaccess control measures Role-based Access Control, as per may berecommended to prevent Industry best practices. identity attacks.

Finally, the Merchant or PSP interface 304 may decrypt the encryptedinformation in token data 304 b to assist in auto-filing fields andpresenting data to users to speed transactions and make transactionsmore trustworthy from a user's perspective.

As a result of the system and the unified format described herein, amerchant may be able to make a single request for a certain type of datawithout regard to the payment service receiving the request. Currently,each payment service has a different way to name each data field, adifferent API to call for certain data, a different manner of deliveringthe data, etc. As a result, a merchant has to add programming for eachpayment service that is supported along with the appropriate APIs foreach payment service. By having a consistent manner of naming data,calling for data, receiving data, etc., the amount of programming maysignificantly drop. Further, the exchange with payment applications maybe more reliable as the data exchange should follow a standard.

A more recent complexity is the use of tokens. Tokens are not actualPANs but may be used as a proxy for a PAN wherein an authority cantranslate the token data 304 b into a PAN but the token data is the onlydata disclosed on a network. By following the blocks of the embodimentsdescribed herein, account data which may be stored by the token server308 may still be accessed and used for autofill purposes to assist usersin filling out forms which can be filled with autofill data. Such datawas often previously unavailable to merchants when tokens were used. Byaddressing this technical problem of user data being hidden behindtokens, the user data may now be available to merchants in an encryptedmanner.

Another benefit may be that expired cards may not limit a user fromusing a payment application to make a purchase. The merchant may requesta valid and unique cryptogram which may be provided even if theunderlying card has expired in certain circumstances. Instead of havingto bother users to enter data on new cards with updated expirationdates, the old card may be leveraged to allow a user to continue to usethe payment application to make payments. In other embodiments, the usermay only have to update an expiration data and all the other card datamay be auto-filled.

With reference to FIG. 4, a system 400 may be utilized forperson-to-person payments or for consumer-to-merchant payments in whichthe payee a merchant displays its account identifier to the payer aconsumer to enable the payer to initiate payments in favor of the payee.In other scenarios, the payer may be a donor wishing to make a donationto the payee, being a charitable organization displaying its accountidentifier on, for example a poster or digital display.

In the embodiments described herein, the payee may provide its accountidentifier to the payer in a tag e.g., tags 304 b, etc. which includes apersonal information flag indicating that certain personal informationof the payer is requested by the payee. Embodiments described herein mayalso include personal information in the tags which may be requested bythe payee including one or more of the group of: a shipping address, anaddress of a contact other than the payer, contact information of thepayer such as an email address and/or a phone number, know-your-customerKYC information, an identity number, a social security number and thelike. Accordingly, and depending on whether the payer grants permissionfor the personal information requested by the payee to be shared withthe payee, the transaction request message may include the requestedpersonal information of the payer 412 which will be shared with thepayee.

The issuer and acquirer server computers 410, 420 respectively may beany appropriate server computers, server computer clusters, distributedserver computers, cloud-based server computers and the like. Each of theserver computers 410, 420 may include a processor and a non-transitorycomputer readable medium comprising code executable by the processor toperform functions, such as generating messages, electronically receivingand transmitting messages or data, parsing messages or data, and thelike. The server computers 410, 420 may be configured to transmit andreceive financial system transaction messages such as ISO 8583 messages,debit and credit financial accounts, transmit messages to and receivemessages from the communication devices 414, 424 respectively and thelike.

The issuer server computer 410 may be maintained or operated byfinancial institution 416 controlling a financial account 418 of thepayer. The financial account of the payer may be associated with anaccount identifier. Similarly, the acquirer server computer 420 may bemaintained or operated by another financial institution 426 controllinga financial account 428 of the payee 412. The financial account 428 ofthe payee 422 may be associated with an account identifier.

The account identifiers of the payer and the payee may include routinginformation usable by the payment processing network 430 in routingfinancial system transaction response messages between the servercomputers 410, 420. The routing information may be a bank identificationnumber BIN associated with the respective financial institution 416, 426and which is usable by the payment processing network 430 in identifyingthe appropriate financial institution 416, 426 to which the financialsystem response messages should be transmitted.

The payment processing network 430 may include data processingsubsystems, networks, server computers and operations used to supportand deliver authorization services, exception file services, andclearing and settlement services. The payment processing network 430 maybe any suitable network able to transmit and receive financial systemtransaction messages e.g., ISO 8583 messages, and process originalcredit and debit card transactions. Payment processing systems are ableto process credit card transactions, debit card transactions, and othertypes of commercial transactions, including virtual card and mobilewallet transactions. The payment processing network 430 may be aninteroperable payment processing network.

The payer's communication device 414 may be any appropriate electronicdevice capable of communicating over a communication network 450. Thecommunication device 414 may be one or more of: a mobile phone, a smartphone, a wearable computing device, tablet computing device, a personaldigital assistant, a laptop or desktop computer or the like. Thecommunication device 414 may have a software application residenttherein and installed thereon which may enable the communication device414 to transmit data messages to and receive data messages from theissuer server computer 410. In other embodiments, the communicationdevice 414 may exchange data messages with the issuer server computer410 using Unstructured Supplementary Service Data USSD sessions or ShortMessaging Service SMS messages via the communication network 450.

The payee's communication device 424 may be any appropriate electronicdevice capable of communicating over the communication network 450.Depending on the application, the payee communication device 424 may bea mobile phone, a point of sales device, an electronic transactionserver or the like. The payee's communication device 424 may also havean appropriate software application resident therein and installedthereon which may enable the communication device 424 to transmit datamessages to and receive data messages from the acquirer server computer420.

By enabling the payer's communication device 414 to exchange messageswith the issuer server computer 410, the payer 412 may be able to usethe communication device 414 to transact against the financial account418 of the payer controlled by the payer's financial institution 416.The payer may be able to initiate transactions in favor of the payee'sfinancial account 428 by using the payer's communication device 414 togenerate and transmit a transaction message, including the accountidentifier of the payee and an amount associated with the transfer offunds, to the issuer server computer 410. When initiating a transactionin favor of the payee, the payer may be able to indicate whether he orshe permits personal information, such as a shipping address or contactinformation, to be shared with the payee.

In response to receiving the transaction message requesting the issuerserver computer 410 to initiate a transfer of funds in favor of thepayee's financial account 428, the issuer server computer 410 debits thefinancial account of the payer and transmits a transaction requestmessage, including the account identifier of the payee and the amount,to the acquirer server computer 420. If the payer has indicated thatpersonal information may be shared with the payee, the issuer servercomputer 410 may include this personal information in the transactionrequest message.

A transaction request message may be any suitable financial systemtransaction message transmitted from the issuer server computer 410 tothe acquirer server computer 420 through the payment processing network430. A transaction request message may be in the standard ISO 8583messaging format, or in any other suitable financial system transactionmessaging format. Suitable messages may also be in an “0200” messageformat. The transaction request message may be an Original CreditTransaction OCT type message.

An OCT is typically a clearing and settlement credit transactiondesigned for use in business applications such as a business moneytransfer or business-to-consumer repayments. A special indicatoridentifies an OCT to the recipient of the message. OCT messages may alsoinclude an Electronic Commerce Indicator ECI to indicate an InternetOCTs if appropriate. Representational State Transfer Extensible MarkupLanguage REST-XML, REST-JavaScript Object Notation REST-JSON, andREST-Name-Value-Pairs REST-NVP templates may be used for the OCT requestmessages. OCT request messages described herein may include an amountassociated with the transfer of funds, an account identifier of thepayee, an account identifier of a payer, personal information of thepayer, a message type indicator, a transaction identifier, currencyinformation and any other appropriate information.

The transaction request message may thus be routed from the paymentprocessing network 430 to the acquirer server computer 420. The acquirerserver computer 420 credits the payee's financial account 128 andtransmits a transaction response message, either confirming or denyingthe transaction, to the issuer server computer 410 via the paymentprocessing network 430. A transaction response message may be anysuitable message transmitted from the acquirer server computer 420 tothe issuer server computer 410 through the payment processing network430, in response to the transaction request message. A transactionresponse message may be in the standard ISO 8583 messaging format, or inany other suitable financial system transaction messaging format. Thetransaction response message may include an indication that the transferof funds was approved or not approved.

The acquirer server computer 420 may transmit a payment confirmationmessage to the payee indicating the amount paid by the payer andincluding the personal information of the payer requested by the payee.The payee may then be able to use the personal information tocommunicate with the payer, for example by shipping a product purchasedby the payer to the address included in the transaction request messageor by acknowledging a donation received from the payer.

Turning now to FIG. 5, components of the payer's communication device414, the issuer server computer 410 and the acquirer server computer 420are illustrated.

The communication device 414 of the payer may include a communicationnetwork interface 502 arranged to enable the communication device 414 tocommunicate with the issuer server computer 410 over the communicationnetwork 450. Further details of an embodiment of a communication deviceare provided with reference to FIG. 9 and described below.

The communication device 414 may include a processor for executing thefunctions of the described components which may be software unitsexecuting on the communication device 414 either being resident thereonor provided remotely. Instructions may be provided to the processor tocarry out the functionality of the described components.

The communication device 414 may host a banking or payment functionalityprovided by a payment application 503 which may include securetransaction capabilities. A payment application 503 may be provided by afinancial institution or payment processing network and may be residenton the communication device 414 or may be provided as a remotely basedservice application.

The payment application 503 may include an obtaining component 504 whichis configured to obtain information from a tag provided by the payee.The obtaining component 504 may include access to hardware components ofthe communication device 414 including one or more of the group of: acamera 504A for capturing information from a tag in the form of agraphical code such as a barcode, two-dimensional barcode or the like;an antenna and transceiver 504B for receiving information from a tag inthe form of a radio frequency beacon such as a Near Field CommunicationNFC, Radio Frequency Identification RFID, Bluetooth™ Low Energy BLEbeacon or the like; and a microphone 504C for receiving information froma tag in the form of a near sound communication beacon. The informationobtained from the tag may include one or more of the group of: anaccount identifier of the payee; a personal information flag indicatingthat personal information of the payer is requested by the payee; anamount e.g. $200; information about the payee such as a name of thepayee, an address of the payee, a merchant category code whereapplicable of the payee and the like.

The payment application 503 may also include a prompting component 506arranged to prompt the payer operating the communication device 414 forpermission to share the requested personal information with the payee.The prompting component 506 may prompt the payer via a message displayedon a display screen 508 of the communication device 414. The promptingcomponent 506 may also display the personal information which will beshared with the payee together with the prompt. In some embodiments, theprompting component 506 may be configured to provide the payer with anoption to edit the personal information which will be shared with thepayee. It is also anticipated that the prompting component 506 may bearranged to provide the payer with an option to select personalinformation of a contact of the payer which will be shared with thepayee, for example, where the payer is purchasing a gift for one of thepayer's contacts.

The payment application 503 may further include an input component 510which is arranged to receive the payer's approval or denial in respectof sharing the requested personal information with the payee. The inputcomponent 510 may further be configured to receive input by the payerediting the personal information to be shared with the payer oralternatively the payer's input as to a contact whose personalinformation should be shared with the payee. In some embodiments, theinput component 510 is further configured to receive an amount input bythe payer in respect of the transfer of funds e.g. where this is notincluded in the information received from the tag.

The payment application 503 may include a generating component 512configured to generate a transaction message. The generating component512 may be arranged to include one or more of: the amount associatedwith the transfer of funds; the account identifier of the payee obtainedfrom the tag; the account identifier of the payer; and a permissionindication indicating the payer's approval or denial in respect ofsharing the requested personal information with the payee in thetransaction message. In some embodiments, the generating component 512includes a retrieving component 512A for retrieving the requestedpersonal information from a digital memory of the communication deviceand including the retrieved personal information with the permissionindication in the transaction message. In other embodiments, thepersonal information may be stored at the issuer server computer 410 forretrieval thereat.

The payment application 503 may also include a transmitting component514 configured to transmit the generated transaction message to theissuer server computer 410 associated with the payer for processing thetransaction and conditional forwarding of the requested personalinformation to the payee. The communication device 414 may furtherinclude a receiving component 516 for receiving a transactionconfirmation or denial message confirming or denying the transaction.The transmitting component 514 and receiving component 516 may use thecommunication network interface 502 to transmit the transaction messageto and receive the transaction confirmation or denial message from theissuer server computer 410 via the communication network 450. The issuerserver computer 410 may include at least one processor, a hardwaremodule, or a circuit for executing the functions of the describedcomponents which may be software units executing on the at least oneprocessor.

The issuer server computer 410 may include a communication networkinterface 520A arranged to enable the issuer server computer 410 tocommunicate with the communication device 414 of the payer over thecommunication network 450. The issuer server computer 410 may include apayment processing network interface 520B configured to enable theissuer server computer 410 to communicate with the payment processingnetwork 430 and in turn the acquirer server computer 420. The paymentprocessing network interface 520B may, for example be configured toparse messages into ISO 8583 formatted messages for transmission overthe payment processing network 430 as well as performing handshaking andother networking operations.

The issuer server computer 410 may also include a payer messagingbcomponent 522 which is configured to receive the transaction messagefrom the communication device 414 of the payer. The payer messagingcomponent 522 may receive the transaction message via the communicationnetwork interface 520A of the issuer server computer 410.

The issuer server computer 410 may also include an identifying component524 arranged to identify a financial account and/or a data recordassociated with the payer. The identifying component 524 may use theaccount identifier of the payer included in the transaction message toidentify the financial account and/or the data record. The identifyingcomponent 524 may also include a debiting component 524A for debitingthe financial account with the amount associated with the transfer offunds.

The issuer server computer 410 may include an evaluating component 526which is arranged to evaluate the permission indication included in thetransaction message to determine whether the payer has granted or deniedpermission to the issuer server computer 410 to share personalinformation requested by the payee with the payee.

In some embodiments, the issuer server computer 410 includes aretrieving component 528 configured to retrieve the requested personalinformation, in respect of which the payer has granted permission forsharing with the payee, from the data record associated with the payer.In other embodiments, the personal information is included with thepermission indication in the transaction message.

The issuer server computer 410 may include a generating component 530arranged to, if the permission indication indicates that the requestedpersonal information may be shared with the payee, generate atransaction request message. The generating component 530 may includeone or more of the amount; the account identifier of the payee; theaccount identifier of the payer; the requested personal information inrespect of which the payer has granted permission for sharing with thepayee; and optionally additional information in the transaction requestmessage. The transaction request message generated by the generatingcomponent 530 may be an OCT request message.

If the permission indication indicates that the requested personalinformation may not be shared with the payee, the generating component530 may be configured to generate a transaction request messageincluding the amount and the account identifier of the payee andoptionally other information. In other embodiments, the transaction mayfail if the permission indication indicates that the requested personalinformation may not be shared with the payee.

The issuer server computer 410 may also include a payment networkmessaging component 532 which is arranged to transmit the transactionrequest message for receipt by the acquirer server computer 420associated with the payee. The payment network messaging component 532may also be arranged to receive a transaction response message from theacquirer server computer either confirming or denying the transaction.The payment network messaging component 532 may send and receivetransaction request and response messages to and from the paymentprocessing network using the payment processing network interface 520B.

The acquirer server computer 420 may include at least one processor, ahardware module, or a circuit for executing the functions of thedescribed components which may be software units executing on the atleast one processor.

The acquirer server computer 420 may include a communication networkinterface 540A arranged to enable the acquirer server computer 420 tocommunicate with the communication device 424 of the payee over thecommunication network 450. The acquirer server computer 420 may includea payment processing network interface 540B configured to enable theacquirer server computer 420 to communicate with the payment processingnetwork 430 and in turn the issuer server computer 410.

The acquirer server computer 420 may include a payment network messagingcomponent 542 for receiving transaction request messages from the issuerserver computer 410 via the payment processing network 430. The paymentnetwork messaging component 542 may also be arranged to transmittransaction response messages to the issuing server computer via thepayment processing network either confirming or denying the transaction.The payment network messaging component 542 may send and receivetransaction response and request messages to and from the paymentprocessing network using the payment processing network interface 5408.

The acquirer server computer 420 may also include an extractingcomponent 544 configured to extract the amount associated with thetransfer of funds, the account identifier of the payee and the personalinformation from the transaction request message.

The acquirer server computer 420 may also include an identifyingcomponent 546 for identifying the financial account of the payeeassociated with the payee account identifier and a crediting component546A for crediting the financial account of the payee with the amount.

The acquirer server computer 420 may further include a payee messagingcomponent 548 arranged to transmit a confirmation or denial message tothe communication device 424 of the payee either confirming or denyingthe transaction. The payment confirmation message may include the amountin respect of the transfer of funds as well as the personal informationwhich was requested by the payee.

It should be appreciated that the issuer server computer 410 may beconfigured to act as and perform the operations of an acquirer servercomputer and vice versa. Thus embodiments of the described systemanticipate an issuer server computer including the components of andbeing able to perform the functions and operations of an acquirer servercomputer and similarly an acquirer server computer including thecomponents of and being able to perform the functions and operations ofan issuer server computer. For example, a server computer may be anacquirer server computer to one entity and an issuer server computer toanother entity. In some cases, depending on whether the entity is apayer or a payee in a particular transaction, the server computer mayact as and perform the operations and functions of an acquirer servercomputer or an issuer server computer as may be required.

An exemplary method 600 for conducting a transaction using the systemdescribed above is illustrated in FIG. 6. Each step of the method may beperformed on a server or other computing device including instructionsthat, when executed by a processor, perform the action or blockdescribed herein.

The method may be implemented in a number of transaction scenarios. Forexample, in one scenario, a payer may be a consumer who notices anadvertisement which advertises a product which the payee a merchant isselling. The advertisement may be a digital display and may include atag in which the account identifier of the payer, an amount which mustbe paid for the product, as well as a personal information flagindicating that certain personal information of the payer will berequired by the payee. The personal information flag may, for example,indicate that the payee will require a shipping address of the payer sothat the product can be shipped to the payer.

In another exemplary scenario, the payee may be a charity appealing todonors to make donations. The payee may place advertisements including atag in public spaces. The tag may include the account identifier of thepayer, a suggested donation amount, as well as a personal informationflag indicating that certain personal information such as an emailaddress of the payer will be required by the payee.

Upon noticing the advertisement and wishing to act on it, the payer mayuse his or her communication device 414 to obtain information from thetag. At a first stage 602, the communication device 414 of the payerobtains information from the tag. The information obtained from the tagmay include an account identifier of the payee, a personal informationflag indicating that personal information of the payer is requested bythe payee, optionally an amount, and optionally additional information.Obtaining the information from the tag may include scanning a graphicalcode or receiving the information from a radio frequency or near soundcommunication beacon.

The communication device 414 may then, at a following stage 604, detectthat the information includes a personal information flag indicatingthat personal information of the payer is requested by the payee. Thepersonal information flag may indicate that one or more of a shippingaddress, an email address, and a phone number of the payer is requestedby the payee.

At a next stage 606, the communication device 414 prompts the payer forpermission to share the requested personal information with the payee.This stage 606 may include displaying the personal information whichwill be shared with the payee to the payer. In some embodiments, thestage 606 of prompting the payer for permission to share personalinformation includes providing the payer with an option to edit thepersonal information which will be shared with the payee and/or with anoption to select personal information of a contact of the payer whichwill be shared with the payee. The prompt may, for example, allow thepayer to select a contact from an address book stored in thecommunication device 414, where the payer is purchasing a gift for thecontact.

The payer may decide that the requested personal information may beshared with the payee or alternatively that he or she does not wish forthe requested personal information to be shared with the payee. Thecommunication device 414 may then receive the payer's approval or denialin respect of sharing the requested personal information with the payeein a following stage 608. This stage 608 may include receiving edits tothe personal information made by the payer and/or personal informationof a contact other than the payer. In some embodiments, the payer mayalso input an amount for example where the payer is making a donation tothe payee while in other embodiments the amount is included in theinformation obtained from the tag.

At a next stage 610, the communication device 414 generates atransaction message including the amount associated with the transfer offunds, the account identifier of the payee, a permission indicationindicating the payer's approval or denial in respect of sharing therequested personal information with the payee and optionally additionalinformation. In some embodiments, the step 610 of generating thetransaction message may include a step of retrieving the requestedpersonal information for inclusion with the permission indication in thetransaction message. In other embodiments this step is performed by theissuer server computer.

At a following stage 612, the communication device 414 transmits thetransaction message to the issuer server computer 410 associated withthe payer for processing the transaction and conditional forwardingdepending on the permission indication included in the message of therequested personal information to the payee.

The issuer server computer 410 then receives the transaction message ata following stage 614. The transaction message may include the amountassociated with the transfer of funds, the account identifier of thepayee, a permission indication indicating the payer's approval or denialin respect of sharing with the payee personal information requested bythe payee, and optionally additional information.

At a following stage 616, the issuer server computer 410 identifies afinancial account and/or a data record associated with the payer, forexample using the account identifier of the payer included in thetransaction message. This stage 616 may include debiting the financialaccount of the payer with the amount associated with the transfer offunds.

The issuer server computer 410 may then, at a following stage 618,evaluate the permission indication included in the transaction messageto determine whether the payer has granted or denied permission to theissuer server computer 410 to share the requested personal informationwith the payee.

If 620 the permission indication indicates that the requested personalinformation may be shared with the payee, the issuer server computer 410may retrieve the requested personal information from the data recordassociated with the payer at a next stage 622. In other embodiments, thepermission indication may include the requested personal information. Ata next stage 624, the issuer server computer 410 may then generate atransaction request message including the amount, the account identifierof the payee, the requested personal information and optionallyadditional information. The transaction request message generated by theissuer server computer may be an OCT request message.

Alternatively, if 620 the permission indication indicates that therequested personal information may not be shared with the payee, theissuer server computer 410 may generate a transaction request messageincluding the amount, the account identifier of the payee and optionallyadditional information at an alternative stage 626. In other cases,where the requested personal information may not be shared with thepayee, the transaction may fail and messages to that effect may betransmitted.

At a following stage 628, the issuer server computer 410 transmits thetransaction request message for receipt by the acquirer server computer420 associated with the payee. Transmitting the transaction requestmessage may transmit the message via the payment processing network.

The acquirer server computer 420 may then receive the transactionrequest message at a following stage 630.

The acquirer server computer 420 may then, at a further stage 632,extract the amount associated with the transfer of funds, the accountidentifier of the payee and the personal information if any from thetransaction request message.

At a next stage 634, the acquirer server computer 420 may identify thefinancial account of the payee associated with the payee accountidentifier and credit the financial account with the amount.

The acquirer server computer 420 may then generate and transmit atransaction response message to the issuer server computer 410 eitherconfirming or denying the transaction at a following stage 636. Thetransaction response message may be an OCT response message.

The acquirer server computer 420 may also transmit a confirmation ordenial message to the communication device of the payee eitherconfirming or denying the transaction at a next stage 638. The paymentconfirmation message may include the amount in respect of the transferof funds as well as the personal information which was requested by thepayee.

Having received the payment confirmation message together with thepersonal information of the payer, the payee may cause the productpurchased by the payee to be shipped; may send an email to the payerthanking the payer for his or her donation or the like.

The issuer server computer 410 may receive the transaction responsemessage at a following stage 640 and may then transmit a paymentconfirmation or denial message to the communication device of the payereither confirming or denying the transaction.

The embodiments described herein thus enable personal information of apayer to be transmitted together with payment information e.g. anaccount identifier of a payee and an amount in respect of the transferof funds to be sent together in a single message. The personalinformation and payment information may thus be received from a singlesource as opposed to disparate sources as may previously have been thecase. Furthermore, embodiments described herein provide for paymentinformation and personal information of the payer to be transmitted overan interoperable payment processing network. Embodiments describedherein provide a system and method in which push payment transactionmessages are transmitted over an interoperable payment processingnetwork and include both payment information and personal information ofthe payer which may be used by the payee.

The system and method described herein may be advantageous in thatreceiving information by payees such as merchants from disparate sourcesis obviated. This may reduce the time and processing required at thepayee to tie related pieces of information together e.g. a paymentconfirmation received from a bank and address information receiveddirectly from the payer.

FIG. 7 is a schematic diagram which illustrates an exemplary scenario ofthe described system and method in use from the perspective of a payer.The payer may notice an advertisement 702 advertising a product for saleby a payee. The advertisement 702 includes a tag 704. The tag 704includes an account identifier of the payee 706, an amount associatedwith the price of the product 708 and a personal information flag 710indicating that the payee requests personal information of the payer.The payer uses his or her communication device 414 to obtain 711 theaccount identifier 706, amount 708 and a personal information flag 710from the tag 704. Responsive to detecting the personal information flag710, the communication device 414 prompts 712 the payer for permissionto share the payer's personal information with the payee. The prompt maydisplay the relevant personal information which will be shared. Thepayer inputs 714 his or her approval indicating that the personalinformation may be shared with payee and causes the communication device414 to transmit a transaction message including a permission indicationindicating the payer's approval in respect of sharing the personalinformation requested by the payee with the payee as well as the amountand the account identifier of the payee. The payer then receives atransaction confirmation message 716 confirming the transaction andindicating that the product will be shipped to the payer's shippingaddress.

FIG. 8 illustrates an example of a computing device 800 in which variousaspects of the embodiments described herein may be implemented. Thecomputing device 800 may be suitable for storing and executing computerprogram code. The various participants and elements in the previouslydescribed system diagrams may use any suitable number of subsystems orcomponents of the computing device 800 to facilitate the functionsdescribed herein.

The computing device 800 may include subsystems or componentsinterconnected via a communication infrastructure 805 for example, acommunications bus, a cross-over bar device, or a network. The computingdevice 800 may include at least one central processor 810 and at leastone memory component in the form of computer-readable media.

The memory components may include system memory 815, which may includeread only memory ROM and random access memory RAM. A basic input/outputsystem BIOS may be stored in ROM. System software may be stored in thesystem memory 815 including operating system software.

The memory components may also include secondary memory 820. Thesecondary memory 820 may include a fixed disk 821, such as a hard diskdrive, and, optionally, one or more removable-storage interfaces 822 forremovable-storage components 823.

The removable-storage interfaces 822 may be in the form ofremovable-storage drives for example, magnetic tape drives, optical diskdrives, floppy disk drives, etc. for corresponding removablestorage-components for example, a magnetic tape, an optical disk, afloppy disk, etc., which may be written to and read by theremovable-storage drive.

The removable-storage interfaces 822 may also be in the form of ports orsockets for interfacing with other forms of removable-storage components823 such as a flash memory drive, external hard drive, or removablememory chip, etc.

The computing device 800 may include an external communicationsinterface 830 for operation of the computing device 800 in a networkedenvironment enabling transfer of data between multiple computing devices800. Data transferred via the external communications interface 830 maybe in the form of signals, which may be electronic, electromagnetic,optical, radio, or other types of signal.

The external communications interface 830 may enable communication ofdata between the computing device 800 and other computing devicesincluding servers and external storage facilities. Web services may beaccessible by the computing device 800 via the communications interface830. The external communications interface 830 may also enable otherforms of communication to and from the computing device 800 including,voice communication, near field communication, Bluetooth™, etc.

The computer-readable media in the form of the various memory componentsmay provide storage of computer-executable instructions, datastructures, program modules, and other data. A computer program productmay be provided by a computer-readable medium having storedcomputer-readable program code executable by the central processor 810.A computer program product may be provided by a non-transientcomputer-readable medium, or may be provided via a signal or othertransient means via the communications interface 830.

Interconnection via the communication infrastructure 805 allows acentral processor 810 to communicate with each subsystem or componentand to control the execution of instructions from the memory components,as well as the exchange of information between subsystems or components.

Peripherals such as printers, scanners, cameras, or the like andinput/output I/O devices such as a mouse, touchpad, keyboard,microphone, joystick, or the like may couple to the computing device 500either directly or via an I/O controller 535. These components may beconnected to the computing device 500 by any number of means known inthe art, such as a serial port. One or more monitors 545 may be coupledvia a display or video adapter 540 to the computing device 500.

FIG. 9 shows a block diagram of a communication device 900 that may beused in embodiments of the disclosure. The communication device 900 maybe a cell phone, a feature phone, a smart phone, a satellite phone, or acomputing device having a phone capability.

The communication device 900 may include a processor 905 e.g., amicroprocessor for processing the functions of the communication device900 and a display 920 to allow a user to see the phone numbers and otherinformation and messages. The communication device 900 may furtherinclude an input element 925 to allow a user to input information intothe device e.g., input buttons, touch screen, etc., a speaker 930 toallow the user to hear voice communication, music, etc., and amicrophone 935 to allow the user to transmit his or her voice throughthe communication device 900.

The processor 905 of the communication device 900 may connect to amemory 915. The memory 915 may be in the form of a computer-readablemedium that stores data and, optionally, computer-executableinstructions.

The communication device 900 may also include a communication element940 for connection to communication channels e.g., a cellular telephonenetwork, data transmission network, Wi-Fi™ network, satellite-phonenetwork, Internet network, Satellite Internet Network, etc. Thecommunication element 940 may include an associated wireless transferelement, such as an antenna.

The communication element 940 may include a subscriber identity moduleSIM in the form of an integrated circuit that stores an internationalmobile subscriber identity and the related key used to identify andauthenticate a subscriber using the communication device 900. One ormore subscriber identity modules may be removable from the communicationdevice 900 or embedded in the communication device 900.

The communication device 900 may further include a contactless element950, which is typically implemented in the form of a semiconductor chipor other data storage element with an associated wireless transferelement, such as an antenna. The contactless element 950 may beassociated with e.g., embedded within the communication device 900 anddata or control instructions transmitted via a cellular network may beapplied to the contactless element 950 by means of a contactless elementinterface not shown. The contactless element interface may function topermit the exchange of data and/or control instructions between mobiledevice circuitry and hence the cellular network and the contactlesselement 950.

The contactless element 950 may be capable of transferring and receivingdata using a near field communications NFC capability or near fieldcommunications medium typically in accordance with a standardizedprotocol or data transfer mechanism e.g., ISO 14443/NFC. Near fieldcommunications capability is a short-range communications capability,such as radio-frequency identification RFID, Bluetooth™′ infra-red, orother data transfer capability that can be used to exchange data betweenthe communication device 900 and an interrogation device. Thus, thecommunication device 900 may be capable of communicating andtransferring data and/or control instructions via both a cellularnetwork and near field communications capability.

The data stored in the memory 915 may include: operation data relatingto the operation of the communication device 900, personal data e.g.,name, date of birth, identification number, etc., financial data e.g.,bank account information, a bank identification number BIN, credit ordebit card number information, account balance information, expirationdate, loyalty provider account numbers, etc., transit information e.g.,as in a subway or train pass, access information e.g., as in accessbadges, etc. A user may transmit this data from the communication device900 to selected receivers.

The communication device 900 may be, amongst other things, anotification device that can receive alert messages and access reports,a portable merchant device that can be used to transmit control dataidentifying a discount to be applied, as well as a portable consumerdevice that can be used to make payments.

The foregoing description of the embodiments of the invention has beenpresented for the purpose of illustration; it is not intended to beexhaustive or to limit the invention to the precise forms disclosed.Persons skilled in the relevant art can appreciate that manymodifications and variations are possible in light of the abovedisclosure.

The user devices, computers and servers described herein may have, amongother elements, a microprocessor such as from the Intel Corporation, AMDor Motorola; volatile and non-volatile memory; one or more mass storagedevices i.e., a hard drive; various user input devices, such as a mouse,a keyboard, or a microphone; and a video display system. The userdevices, computers and servers described herein may be running on anyone of many operating systems including, but not limited to WINDOWS,UNIX, LINUX, MAC OS, or Windows XP, VISTA, etc. It is contemplated,however, that any suitable operating system may be used for the presentinvention. The servers may be a cluster of web servers, which may eachbe LINUX based and supported by a load balancer that decides which ofthe cluster of web servers should process a request based upon thecurrent request-load of the available servers.

The user devices, computers and servers described herein may communicatevia networks, including the Internet, WAN, LAN, Wi-Fi, other computernetworks now known or invented in the future, and/or any combination ofthe foregoing. It should be understood by those of ordinary skill in theart having the present specification, drawings, and claims before themthat networks may connect the various components over any combination ofwired and wireless conduits, including copper, fiber optic, microwaves,and other forms of radio frequency, electrical and/or opticalcommunication techniques. It should also be understood that any networkmay be connected to any other network in a different manner. Theinterconnections between computers and servers in system are examples.Any device described herein may communicate with any other device viaone or more networks.

The example embodiments may include additional devices and networksbeyond those shown. Further, the functionality described as beingperformed by one device may be distributed and performed by two or moredevices. Multiple devices may also be combined into a single device,which may perform the functionality of the combined devices.

The various participants and elements described herein may operate oneor more computer apparatuses to facilitate the functions describedherein. Any of the elements in the above-described Figures, includingany servers, user devices, or databases, may use any suitable number ofsubsystems to facilitate the functions described herein.

Any of the software components or functions described in thisapplication, may be implemented as software code or computer readableinstructions that may be executed by at least one processor using anysuitable computer language such as, for example, Java, C++, or Perlusing, for example, conventional or object-oriented techniques.

The software code may be stored as a series of instructions or commandson a non-transitory computer readable medium, such as a random accessmemory RAM, a read only memory ROM, a magnetic medium such as ahard-drive or a floppy disk, or an optical medium such as a CD-ROM. Anysuch computer readable medium may reside on or within a singlecomputational apparatus and may be present on or within differentcomputational apparatuses within a system or network.

It may be understood that the present invention as described above canbe implemented in the form of control logic using computer software in amodular or integrated manner. Based on the disclosure and teachingsprovided herein, a person of ordinary skill in the art may know andappreciate other ways and/or methods to implement the present inventionusing hardware, software, or a combination of hardware and software.

The above description is illustrative and is not restrictive. Manyvariations of the invention will become apparent to those skilled in theart upon review of the disclosure. The scope of the invention should,therefore, be determined not with reference to the above description,but instead should be determined with reference to the pending claimsalong with their full scope or equivalents.

One or more features from any embodiment may be combined with one ormore features of any other embodiment without departing from the scopeof the invention. A recitation of “a”, “an” or “the” is intended to mean“one or more” unless specifically indicated to the contrary. Recitationof “and/or” is intended to represent the most inclusive sense of theterm unless specifically indicated to the contrary.

One or more of the elements of the present system may be claimed asmeans for accomplishing a particular function. Where suchmeans-plus-function elements are used to describe certain elements of aclaimed system it will be understood by those of ordinary skill in theart having the present specification, figures and claims before them,that the corresponding structure is a general purpose computer,processor, or microprocessor as the case may be programmed to performthe particularly recited function using functionality found in anygeneral purpose computer without special programming and/or byimplementing one or more algorithms to achieve the recitedfunctionality. As would be understood by those of ordinary skill in theart that algorithm may be expressed within this disclosure as amathematical formula, a flow chart, a narrative, and/or in any othermanner that provides sufficient structure for those of ordinary skill inthe art to implement the recited process and its equivalents.

While the present disclosure may be embodied in many different forms,the drawings and discussion are presented with the understanding thatthe present disclosure is an exemplification of the principles of one ormore inventions and is not intended to limit any one of the inventionsto the embodiments illustrated.

The present disclosure provides a solution to the long-felt needdescribed above. In particular, the systems and methods described hereinmay be configured for improving payment systems. Further advantages andmodifications of the above described system and method will readilyoccur to those skilled in the art. The disclosure, in its broaderaspects, is therefore not limited to the specific details,representative system and methods, and illustrative examples shown anddescribed above. Various modifications and variations can be made to theabove specification without departing from the scope or spirit of thepresent disclosure, and it is intended that the present disclosurecovers all such modifications and variations provided they come withinthe scope of the following claims and their equivalents.

Additionally, certain embodiments are described herein as includinglogic or a number of components, modules, or mechanisms. Modules mayconstitute either software modules e.g., code or instructions embodiedon a machine-readable medium or in a transmission signal, wherein thecode is executed by a processor or hardware modules. A hardware moduleis tangible unit capable of performing certain operations and may beconfigured or arranged in a certain manner. In example embodiments, oneor more computer systems e.g., a standalone, client or server computersystem or one or more hardware modules of a computer system e.g., aprocessor or a group of processors may be configured by software e.g.,an application or application portion as a hardware module that operatesto perform certain operations as described herein.

In various embodiments, a hardware module may be implementedmechanically or electronically. For example, a hardware module maycomprise dedicated circuitry or logic that is permanently configurede.g., as a special-purpose processor, such as a field programmable gatearray FPGA or an application-specific integrated circuit ASIC to performcertain operations. A hardware module may also comprise programmablelogic or circuitry e.g., as encompassed within a general-purposeprocessor or other programmable processor that is temporarily configuredby software to perform certain operations. It will be appreciated thatthe decision to implement a hardware module mechanically, in dedicatedand permanently configured circuitry, or in temporarily configuredcircuitry e.g., configured by software may be driven by cost and timeconsiderations.

Accordingly, the term “hardware module” should be understood toencompass a tangible entity, be that an entity that is physicallyconstructed, permanently configured e.g., hardwired, or temporarilyconfigured e.g., programmed to operate in a certain manner or to performcertain operations described herein. As used herein,“hardware-implemented module” refers to a hardware module. Consideringembodiments in which hardware modules are temporarily configured e.g.,programmed, each of the hardware modules need not be configured orinstantiated at any one instance in time. For example, where thehardware modules comprise a general-purpose processor configured usingsoftware, the general-purpose processor may be configured as respectivedifferent hardware modules at different times. Software may accordinglyconfigure a processor, for example, to constitute a particular hardwaremodule at one instance of time and to constitute a different hardwaremodule at a different instance of time.

Hardware modules can provide information to, and receive informationfrom, other hardware modules. Accordingly, the described hardwaremodules may be regarded as being communicatively coupled. Where multipleof such hardware modules exist contemporaneously, communications may beachieved through signal transmission e.g., over appropriate circuits andbuses that connect the hardware modules. In embodiments in whichmultiple hardware modules are configured or instantiated at differenttimes, communications between such hardware modules may be achieved, forexample, through the storage and retrieval of information in memorystructures to which the multiple hardware modules have access. Forexample, one hardware module may perform an operation and store theoutput of that operation in a memory device to which it iscommunicatively coupled. A further hardware module may then, at a latertime, access the memory device to retrieve and process the storedoutput. Hardware modules may also initiate communications with input oroutput devices, and can operate on a resource e.g., a collection ofinformation.

The various operations of example methods described herein may beperformed, at least partially, by one or more processors that aretemporarily configured e.g., by software or permanently configured toperform the relevant operations. Whether temporarily or permanentlyconfigured, such processors may constitute processor-implemented modulesthat operate to perform one or more operations or functions. The modulesreferred to herein may, in some example embodiments, compriseprocessor-implemented modules.

Similarly, the methods or routines described herein may be at leastpartially processor-implemented. For example, at least some of theoperations of a method may be performed by one or processors orprocessor-implemented hardware modules. The performance of certain ofthe operations may be distributed among the one or more processors, notonly residing within a single machine, but deployed across a number ofmachines. In some example embodiments, the processor or processors maybe located in a single location e.g., within a home environment, anoffice environment or as a server farm, while in other embodiments theprocessors may be distributed across a number of locations.

The one or more processors may also operate to support performance ofthe relevant operations in a “cloud computing” environment or as a“software as a service” SaaS. For example, at least some of theoperations may be performed by a group of computers as examples ofmachines including processors, these operations being accessible via anetwork e.g., the Internet and via one or more appropriate interfacese.g., application program interfaces APIs.

The performance of certain of the operations may be distributed amongthe one or more processors, not only residing within a single machine,but deployed across a number of machines. In some example embodiments,the one or more processors or processor-implemented modules may belocated in a single geographic location e.g., within a home environment,an office environment, or a server farm. In other example embodiments,the one or more processors or processor-implemented modules may bedistributed across a number of geographic locations.

Some portions of this specification are presented in terms of algorithmsor symbolic representations of operations on data stored as bits orbinary digital signals within a machine memory e.g., a computer memory.These algorithms or symbolic representations are examples of techniquesused by those of ordinary skill in the data processing arts to conveythe substance of their work to others skilled in the art. As usedherein, an “algorithm” is a self-consistent sequence of operations orsimilar processing leading to a desired result. In this context,algorithms and operations involve physical manipulation of physicalquantities. Typically, but not necessarily, such quantities may take theform of electrical, magnetic, or optical signals capable of beingstored, accessed, transferred, combined, compared, or otherwisemanipulated by a machine. It is convenient at times, principally forreasons of common usage, to refer to such signals using words such as“data,” “content,” “bits,” “values,” “elements,” “symbols,”“characters,” “terms,” “numbers,” “numerals,” or the like. These words,however, are merely convenient labels and are to be associated withappropriate physical quantities.

Unless specifically stated otherwise, discussions herein using wordssuch as “processing,” “computing,” “calculating,” “determining,”“presenting,” “displaying,” or the like may refer to actions orprocesses of a machine e.g., a computer that manipulates or transformsdata represented as physical e.g., electronic, magnetic, or opticalquantities within one or more memories e.g., volatile memory,non-volatile memory, or a combination thereof, registers, or othermachine components that receive, store, transmit, or displayinformation.

As used herein any reference to “some embodiments” or “an embodiment” or“teaching” means that a particular element, feature, structure, orcharacteristic described in connection with the embodiment is includedin at least one embodiment. The appearances of the phrase “in someembodiments” or “teachings” in various places in the specification arenot necessarily all referring to the same embodiment.

Some embodiments may be described using the expression “coupled” and“connected” along with their derivatives. For example, some embodimentsmay be described using the term “coupled” to indicate that two or moreelements are in direct physical or electrical contact. The term“coupled,” however, may also mean that two or more elements are not indirect contact with each other, but yet still co-operate or interactwith each other. The embodiments are not limited in this context.

Further, the figures depict preferred embodiments for purposes ofillustration only. One skilled in the art will readily recognize fromthe following discussion that alternative embodiments of the structuresand methods illustrated herein may be employed without departing fromthe principles described herein

Upon reading this disclosure, those of skill in the art will appreciatestill additional alternative structural and functional designs for thesystems and methods described herein through the disclosed principlesherein. Thus, while particular embodiments and applications have beenillustrated and described, it is to be understood that the disclosedembodiments are not limited to the precise construction and componentsdisclosed herein. Various modifications, changes and variations, whichwill be apparent to those skilled in the art, may be made in thearrangement, operation and details of the systems and methods disclosedherein without departing from the spirit and scope defined in anyappended claims.

1. A payment transaction system comprising: a token requestor module forreceiving tag data associated with an e-commerce transaction for goodsor services, the tag data including an indication that a merchantpayment webpage is configured to receive a payment transaction via atoken; and a token service for creating one or more tokens from apersonal account number and a shipping address corresponding to thepersonal account number in response to a request for token data from thetoken requestor module; wherein the token requestor module includes aninstruction to push the one or more tokens to the merchant paymentwebpage.
 2. The system of claim 1, wherein the token requestor isfurther for validating the tag data.
 3. The system of claim 1, whereinthe token requestor is further for receiving an input indicatingselection of a payment device.
 4. The system of claim 1, wherein thecryptogram includes payment device data and shipping data.
 5. The systemof claim 1, wherein the token requestor module includes a furtherinstruction to encrypt the token before pushing the token to themerchant payment webpage.
 6. The system of claim 1, wherein the tokenservice is further for creating one or more cryptogams that eachcorrespond to a token of the one or more tokens.
 7. The system of claim6, wherein the merchant payment webpage is configured to send the tokenand a cryptogram corresponding to the token to an issuer server.
 8. Thesystem of claim 7, wherein the token service is further for receivingthe personal account number corresponding to the token and an approvaldecision from the issuer server.
 9. The system of claim 8, wherein thetoken service is further for exchanging the personal account number forthe token.
 10. The system of claim 9, wherein the merchant paymentwebsite is configured to map the token to an e-commerce authorizationrequest and to send the request and token to the issuer server.
 11. Amethod for completing an e-commerce payment transaction comprising:receiving tag data associated with an e-commerce transaction for goodsor services, the tag data including an indication that a merchantpayment webpage is configured to receive a payment transaction via atoken; creating one or more tokens from a personal account number and ashipping address corresponding to the personal account number inresponse to a request for token data from the token requestor module;and pushing the one or more tokens to the merchant payment webpage. 12.The method of claim 11, further comprising validating the tag data. 13.The method of claim 11, further comprising receiving an input indicatingselection of a payment device.
 14. The method of claim 11, wherein thecryptogram includes payment device data and shipping data.
 15. Themethod of claim 11, further comprising encrypting the token beforepushing the token to the merchant payment webpage.
 16. The method ofclaim 11, further comprising creating one or more cryptogams that eachcorrespond to a token of the one or more tokens.
 17. The method of claim16, further comprising sending the token and a cryptogram correspondingto the token to an issuer server.
 18. The method of claim 17, furthercomprising receiving the personal account number corresponding to thetoken and an approval decision from the issuer server.
 19. The method ofclaim 18, further comprising exchanging the personal account number forthe token.
 20. The method of claim 19, further comprising mapping thetoken to an e-commerce authorization request and sending the request andtoken to the issuer server.